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Following is an issue-by-issue reply to the Examiner's Answer. 



Issue # 1 : 

The Examiner has rejected Claims 1, 3, 5-7, 9, 10, 12, 14-16, 18, 19, and 39-41 under 35 U.S.C. 
103(a) as being unpatentable over Ferguson (U.S. Patent No. 6,769,019) in view of Sheldon et al. 
(U.S. Patent No. 6,072,486), and in further view of Anuff et al. (U.S. Publication No. 
2002/0029296). 

Group #1: Claims 7, 5-7, 9, 10, 14-16, 18, 19, and 40 

With respect to independent Claims 1,10, and 19, and particularly appellant's claimed "linking 
the toolbar to a portal of a user," the Examiner has admitted that "Ferguson fails to explicitly 
teach the linking of a portal of a user to a toolbar." 

The Examiner has argued, however, that "Sheldon teaches.a system and method for use with web 
browser toolbars, similar to those of Ferguson," and that "Sheldon teaches the ability to 
customize the toolbar of a user interface by adding, deleting, or changing the function of an 
associated button (col. 1, lines 44-48), or further, dragging and dropping components into a 
toolbar or deskbar, as can be seen in col. 19, line 61 through col. 20, line 14, as the user can drag 
an address bar (similar to the bucket of Ferguson, as input is entered into the bar resulting in a 
desired output) into any deskbar." The Examiner has also argued that "Sheldon further states 
that the deskbar may be placed in an application window, such as a web browser, at col. 6, lines 
62-65." The Examiner has thus concluded that "the incorporation of the GUI 246, and its link to 
the displayed portal in Ferguson, is made possible by the toolbar customization of Sheldon." 

Appellant respectfully disagrees and asserts that only generally teaching "toolbars [that] can be 
modified by adding or deleting buttons, or by changing the function associated with a button" 
(Col. 1, lines 44-46), as in Sheldon, fails to even suggest, let alone specifically meet appellant's 
claimed " linking the toolbar to a portal of a user " (emphasis added), as claimed. In addition, 
appellant respectfully points out that Sheldon does not teach that "the user can drag an address 
bar... into any deskbar," as noted by the Examiner. Instead, Sheldon simply discloses that a 
"user can drag and drop a toolbar associated with [an] application window on some other 
area... on the display screen 300," such that "a deskbar is automatically created containing the 
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toolbar" (see Col. 20, lines 1-6), which clearly only relates to creating a deskbar that contains a 
selected toolbar. Appellant respectfully asserts that only generally disclosing a technique for 
creating a deskbar that contains a selected toolbar, as in Sheldon, fails to specifically teach 
" Unking the toolbar to a portal of a user" (emphasis added), as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "Sheldon explicidy 
outlines 'a method for customizing a deskbar', wherein 'if the user desires to customize the 
taskbar 310 by adding an address bar 600', the use can drag the address toolbar 600 from the 
application window 800' and drop the address bar 600 on top of the taskbar 310.'" Further, the 
Examiner has argued that 'Sheldon does indeed teach that 'the user can drag and address 
bar... into any deskbar'." Additionally, the Examiner has stated that "the current citation of 
Sheldon has been expanded to cover col. 20, lines 15-41, where previously the examiner closed 
the citation at col. 20, line 14." 

Appellant respectfully disagrees and asserts that Sheldon merely teaches that "[i]n FIG. 20a, if 
the user desires to customize the taskbar 3 10 by adding an address toolbar 60Q \ the user can drag 
the address toolbar 600 from the application window 800' and drop the address toolbar 600 on 
top of the taskbar 310" such that " |Ylhe address toolbar 600 is copied during the dragging 
process " (Col. 20, lines 25-3 1 - emphasis added). 

However, teaching that the user can drag the address toolbar from the application window and 
drop the address toolbar on top of the taskbar to customize the taskbar by adding an address 
toolbar , where the address toolbar is copied during the dragging process , as in Sheldon, fails to 
suggest " linking the toolbar to a portal of a user" (emphasis added), as claimed. Clearly, 
copying the address toolbar during the dragging process and customizing the taskbar by adding 
an address toolbar as in Sheldon, simply fails to even suggest "linking the toolbar to a portal of 
a user" (emphasis added), as claimed. 

Still yet, Sheldon's disclosure of a "deskbar [that] may simultaneously contain toolbars and 
toolbar components..., and [that] may exist in an application window" (Col. 6, lines 62-65), as 
referenced by the Examiner, only suggests allowing a deskbar to exist in an a pplication window. 
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which does not meet appellant's claimed " Unking the toolbar to a portal of a user" (emphasis 
added), as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "as in previous 
Office actions,... incorporation of the 'bucket 5 of Ferguson into the customizable toolbar of 
Sheldon links the toolbar to the portal, as the bucket provides a direct link to the portal." 

First, appellant respectfully disagrees and again asserts that Sheldon's disclosure of a "deskbar 
[that] may simultaneously contain toolbars and toolbar components..., and [that] may exist in an 
application window" (Col. 6, lines 62-65), as referenced by the Examiner, only suggests 
allowing a deskbar to exist in an application window , which does not meet appellant's claimed 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Further, appellant respectfully asserts that Ferguson teaches that "[i]n the case of any secondary 
request being initiated by the user dragging-&-dropping a hyperlink from a Web page , the 
invention generates the appropriate HTTP request, fetches the data from the requested Web 
server 10, and archives the information in a cache on the user's hard drive 36" (Col. 7, lines 9-14 
- emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user desires to 
customize the taskbar 310 by adding an address toolbar 600 1 . the user can drag the address 
toolbar 600 from the application window 800 f and drop the address toolbar 600 on top of the 
taskbar 310 " such that " IVIhe address toolbar 600 is copied during the dragging process " (Col. 
20, lines 25-3 1 - emphasis added). 

However, dragging and dropping a hyperlink from a Web page, fetching the data from the 
requested Web server, and archiving the information in a cache on the user's hard drive, as in 
Ferguson, in addition to dragging the address toolbar from the application window and dropping 
the address toolbar on top of the taskbar to customize the taskbar by adding an address toolbar 
where the address toolbar is copied during the dragging process, as in Sheldon, fails to suggest 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. Clearly, fetching data 
and archiving the information, as in Ferguson, in addition to customizing the taskbar by adding 
an address toolbar and copying the address toolbar during the dragging process, as in Sheldon, 
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simply fails to suggest any sort of "linking," much less " linking the toolbar to a portal of a user" 
(emphasis added), as claimed. 

Moreover, appellant respectfully disagrees with the Examiner's argument that "incorporation of 
the GUI 246, and its link to the displayed portal in Ferguson, is made possible by the toolbar 
customization of Sheldon." Appellant respectfully notes that the Examiner has expressly relied 
on the GUI 246 in Ferguson to meet appellant's claimed portal, as expressed by the Examiner's 
statement that "the open GUI [is] analogous to the claimed 'portal'" (see Page 2 of the Office 
Action). Since the Examiner has relied on the GUI 246 in Ferguson to meet appellant's claimed 
portal such GUI clearly cannot have a " link to the displayed portal in Ferguson" (emphasis 
added), as noted by the Examiner. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "[a]ppellant... [has] 
misinterpreted the rejection of the claims with respect to the GUI 246 of Ferguson and the 
claimed portal" and that "GUI 246... teach[es] the claimed 'bucket', not the claimed 'portal', as 
argued by [a]ppellant " Further, the Examiner has argued that "[t]his distinction is highlighted 
by Figs. 7 and 8 of Ferguson" where "Fig. 7 depicts the 'bucket' as referred to by the examiner." 
Additionally, the Examiner has argued that "the user drags links into the GUI 246, the links then 
being added to the 'portal', interpreted by the [E]xaminer as the list of links selected by the user 
in item 261 of Fig. 8." In addition, the Examiner has argued that "[t]he 'open GUI' referred to 
by the [E]xaminer is not simply GUI 246, but instead the expanded GUI of Fig. 8, and more 
specifically, the list of links 261.". 

Appellant respectfully disagrees and asserts that Ferguson teaches that " Itlhe O-Links list display 
261 is depicted in FIG. 8" such that "[w]hen the user opens the maximized graphical user 
interface (GUI) 251, this invokes the Q-Links Manager, as depicted in the flowchart FIG. 20 at 
164," and that "[i]n step 166, the invention obtains the O-Links list and displays it on the 
maximized GUI 251 in step 168" (Col. 30, line 66-Col. 31, line 4 - emphasis added). Further, 
Ferguson teaches that "[i]f the user left clicks (or equivalent), on the link name or Web address 
of the O-Link which appears in the O-Links display list 261 that he/she wishes to view in the 
browser 62, the invention returns with that page from the invention's hard disk Cache 420" (Col. 
31, lines 39-45 - emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user 
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desires to customize the taskbar 310 by adding an address toolbar 600 f . the user can drag the 
address toolbar 600 from the application window 800' and drop the address toolbar 600 on top of 
the taskbar 310 " such that " |Y|he address toolbar 600 is copied during the dragging process" (Col. 
20, lines 25-31 - emphasis added). 

However, teaching a O-Link . which appears in the O-Links display list 26 L as in Ferguson, in 
addition to dragging the address toolbar from the application window and dro pping the address 
toolbar on top of the taskbar, where the address toolbar is copied during the dragging process, as 
in Sheldon, simply fails to suggest " linking the toolbar to a portal of a user" (emphasis added), 
as claimed. Clearly, a Q-Link a ppearing in the O-Links display list 261, as in Ferguson, in 
addition to dro pping the address toolbar on top of the taskbar. as in Sheldon, simply fails to even 
suggest "linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Additionally, it appears that the Examiner has relied on an inherency argument regarding the 
above emphasized claim limitations. In view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific prior 
art showing of such claim features, in combination with the remaining claim elements is 
respectfully requested. (See MPEP 2112) 

Further, in response, appellant asserts that the fact that a certain result or characteristic may 
occur or be present in the prior art is not sufficient to establish the inherency of that result or 
characteristic. In re Rijckaert, 9 F.3d 1531, 1534, 28 USPQ2d 1955, 1957 (Fed. Cir. 1993); In re 
Oelrich, 666 F.2d 578, 581-82, 212 USPQ 323, 326 (CCPA 1981). "To establish inherency, the 
extrinsic evidence 'must make clear that the missing descriptive matter is necessarily present in 
the thing described in the reference, and that it would be so recognized by persons of ordinary 
skill. Inherency, however, may not be established by probabilities or possibilities. The mere fact 
that a certain thing may result from a given set of circumstances is not sufficient.*" In re 
Robertson, 169 F.3d 743, 745, 49 USPQ2d 1949, 1950-51 (Fed. Cir. 1999). 

Still yet, the Examiner has argued that "[a]s the bucket of Ferguson is linked to the user portal, 
any incorporation of the bucket into a toolbar (as done by Sheldon) therefore links the toolbar to 
the user portal." 
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Appellant respectfully disagrees and again points out that Sheldon merely discloses that a "user 
can drag and drop a toolbar associated with [an] application window on some other area.. .on the 
display screen 300," such that "a deskbar is automatically created containing the toolbar" (see 
Col. 20, lines 1-6), which clearly only relates to creating a deskbar that contains a selected 
toolbar. Appellant respectfully asserts that merely allowing a user to drag and drop a toolbar on 
some area of a display screen, where a deskbar containing the toolbar is created, as in Sheldon, 
fails to support the Examiner's allegation that Sheldon teaches "incorporation of the bucket into 
a toolbar " (emphasis added). To this end, the excerpts from Ferguson and Sheldon, as relied on 
by the Examiner, do not meet "linking the toolbar to a portal of a user," as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "the combination of 
the bucket and portal of Ferguson into the customizable toolbars of Sheldon would indeed 
necessarily provide a link from the toolbar to the portal of a user." Further, the Examiner has 
argued that "Sheldon has been shown to teach a link between a bucket and a portal, as indicated 
by the ability of a user to drag and drop links into the bucket GUI 246, the links then being 
shown in the portal list 261." In addition, the Examiner has argued that "it [is believed] to be 
inherent that adding the bucket/portal functionality of Ferguson into the toolbar of Sheldon 
would indeed provide a link from the toolbar to the portal, and is not 'established by probabilities 
or possibilities'." 

Appellant respectfully disagrees and asserts that Ferguson teaches that "HTTP requests Tare! 
issued by dragging-&-dropping hyperlinks on the interface 246 of the invention" (Col. 6, lines 
63-65 - emphasis added). Further, Ferguson teaches that "[i]n the case of any secondary request 
being initiated by the user dragging-&-dropping a hyperlink from a Web page , the invention 
generates the appropriate HTTP request, fetches the data from the requested Web server 10, and 
archives the information in a cache on the user's hard drive 36" such that "[u]pon receiving page 
requests from the list of links downloaded in the background (known as O-Links V the files 
associated with the request are retrieved from the iocal hard drive cache' " (Col. 7, lines 9-20 - 
emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user desires to 
customize the taskbar 310 by adding an address toolbar 600 \ the user can drag the address 
toolbar 600 from the application window 800' and drop the address toolbar 600 on top of the 
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taskbar 310 " such that " [t]he address toolbar 600 is copied during the dragging process " (Col. 
20, lines 25-3 1 - emphasis added). 

However, dragging-&-dropping hyperlinks on the interface 246, generating the appropriate 
HTTP request , fetching the data from the requested Web server 10, and archiving the 
information in a cache on the user's hard drive 36, where the files associated with the request are 
retrieved from the 'local hard drive cache' upon receiving page requests from the list of links (Q- 
Links), as in Ferguson, in addition dragging and dropping the address toolbar 600 on top of the 
taskbar 310 in order to customize the taskbar by adding an address toolbar 600 . as in Sheldon, 
simply fails to suggest " linking the toolbar to a portal of a user" (emphasis added), as claimed. 
Clearly, adding the address toolbar to the taskbar by dragging and dropping , as in Sheldon, in 
addition to dragging and dropping hyperlinks on the interface 246 to generate a HTTP request, 
fetch the data, and archive the information in a cache, as Ferguson, simply fails to even suggest 
' jinking the toolbar to a portal of a user" (emphasis added), as claimed. 

Furthermore, Sheldon teaches that "[t]he address toolbar allows the user to enter a Web address 
to open a Web page without having to open the web browser application program 37 (FIG. 1)" 
(Col. 14, lines 58*60 - emphasis added). However, adding the address toolbar to the taskbar, 
which allows the user to enter a Web address to open a Web page without having to open the 
web browser, as in Sheldon, simply fails to even suggest " linking the toolbar to a portal of a 
user" (emphasis added), as claimed. Clearly, adding an address toolbar that allows the user to 
open a Web page , as in Sheldon, in addition to dragging and dropping hyperlinks on the interface 
246, generating the HTTP request, fetching the data, and archiving the information in a cache, as 
in Ferguson, simply fails to even suggest "linking the toolbar to a portal of a user" (emphasis 
added), as claimed. 

Appellant respectfully asserts that in view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific prior 
art showing of such claim features, in combination with the remaining claim elements is 
respectfully requested. (See MPEP 2112) 
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To establish a prima facie case of obviousness, three basic criteria must be met. First, there must 
be some suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to combine 
reference teachings. Second, there must be a reasonable expectation of success. Finally, the prior 
art reference (or references when combined) must teach or suggest all the claim limitations. The 
teaching or suggestion to make the claimed combination and the reasonable expectation of 
success must both be found in the prior art and not based on appellant's disclosure. In re 
Vaeck t 9Al F.2d 488, 20 USPQ2d 1438 (Fed.Cir.1991). 

Appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art excerpts, as relied upon by the Examiner, fail to 
teach or suggest all of the claim limitations, as noted above. 

Group #2: Claims 3 arid 12 

With respect to independent Claim 3 et al., the Examiner has relied on Col. 1, lines 44-48 in 
Sheldon to make a prior art showing of appellant's claimed technique "wherein the toolbar 
includes a customize button, wherein a customization screen is opened upon selection of the 
customize button, wherein features of the toolbar can be manipulated using the customization 
screen." 

Appellant respectfully notes that the above excerpt relied on by the Examiner merely states that 
"the toolbars can be modified by adding or deleting buttons, or by changing the function 
associated with a button" (Col. 1, lines 44-46). However, simply describing that toolbars can be 
modified by adding or deleting buttons and changing button function, as in Sheldon, fails to 
disclose "a customize button," much less a technique "wherein the toolbar includes a customize 
button , wherein a customization screen is opened upon selection of the customize button, 
wherein features of the toolbar can be manipulated using the customization screen" (emphasis 
added), as claimed by appellant. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "[a]s taught by 
Sheldon, the function associated with a button may be modified or changed (col. 1, lines 44-46)" 
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and that "Sheldon teaches a menu that allows a user to customize features of a toolbar, as seen in 
Fig. 4b " Further, the Examiner has argued that "one of ordinary skill in the art would be able to 
create or modify a button on a toolbar capable of accessing the customization menu of Fig. 4b." 

Appellant respectfully disagrees and asserts that Sheldon teaches that "the toolbars can be 
modified by adding or deleting buttons , or by changing the function associated with a button " 
(Col. 1, lines 44-46 - emphasis added). Further, Sheldon teaches that "[t]he context menu 325 
includes a list of commands 326" and that "[o]f particular interest is a toolbar command 327. 
which triggers a sub-menu 335 ., as shown in FIG. 4b" (Col. 14, lines 45-48 - emphasis added). 
In addition, Sheldon teaches that "[Referring to FIG. 4b, the sub-menu 335 is displayed by 
selecting the toolbar command 327 using the mouse 42," where "[t]he sub-menu 335 includes a 
list of 'registered' toolbar options 340a-340d and a new toolbar option 340e" (Col. 14, lines 49- 
52 - emphasis added). 

However, disclosing that toolbars can be modified by adding or deleting buttons , or by changing 
the function associated with a button, and in addition to disclosing that a toolbar command 327 
triggers a sub-menu 335. where the sub-menu 335 includes a list of 'registered' toolbar options 
and a new toolbar option , as in Sheldon, fails to disclose "a customize button," much less a 
technique "wherein the toolbar includes a customize button , wherein a customization screen is 
opened upon selection of the customize button , wherein features of the toolbar can be 
manipulated using the customization screen" (emphasis added), as claimed by appellant. 
Clearly, a toolbar command triggering a sub-menu that includes a list of registered toolbar 
options and a new toolbar option, as in Sheldon, simply fails to even suggest that "the toolbar 
includes a customize button, wherein a customization screen is opened upon selection of the 
customize button, wherein features of the toolbar can be manipulated using the customization 
screen" (emphasis added), as claimed by appellant. 

Furthermore, appellant asserts that Sheldon teaches that "[w]hen the cursor is positioned over the 
empty area or the header, the user clicks the right mouse button to open the context menu 325. 
and the context menu 325 appears on the display screen 300" (Col. 14, lines 42-45 - emphasis 
added). Furthermore, Sheldon teaches that "[t]o open the context menu 325, the user can either 
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move a cursor (not shown) over an empty area of the deskbar 310, i.e., where an icon or other 
component cannot be mistakenly selected " (Col. 14, lines 35-38 - emphasis added). 

However, clicking the mouse button while positioned over the header or the empty area, where 
an icon or other component cannot be mistakenly selected, to open context menu 325 . which 
includes a list of commands 326 such as a toolbar command 327 that triggers a sub-menu 335, as 
in Sheldon, simply teaches away from "a customization screen is opened upon selection of the 
customize button " (emphasis added), as claimed by appellant. Clearly, clicking the header or an 
empty area , where an icon or other component cannot be selected, to open context menu 325, as 
in Sheldon, simply teaches away from a "selection of the customize button " (emphasis added), as 
claimed by appellant. 

Additionally, appellant respectfully asserts that, as argued hereinabove, it would not be obvious 
"to create or modify a button on a toolbar capable of accessing the customization menu of Fig. 
4b," as alleged by the Examiner. Appellant thus formally requests a specific showing of the 
subject matter in ALL of the claims in any future action. Note excerpt from MPEP below. 

"If the [appellant] traverses such an [Official Notice] assertion the examiner should cite a 
reference in support of his or her position." See MPEP 2144.03. 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art excerpts, as relied upon by the Examiner, fail to 
teach or suggest all of the claim limitations, as noted above. 

Group #3: Claim 39 

With respect to dependent Claim 39, the Examiner has only generally stated that "Ferguson and 
Sheldon teach adding functionality to a toolbar or deskbar, where that functionality may be the 
bucket of Ferguson, or a button with similar functionality, as taught above by Sheldon," to make 
a prior art showing of appellant's claimed technique "wherein the bucket includes a button on the 
toolbar" 
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Appellant respectfully asserts that Sheldon only generally discloses that "toolbars can be 
modified by... changing the function associated with the button" (Col. 1, lines 44-46). Clearly, 
such a general disclosure does not even suggest any sort of "bucket," as appellant claims. 
Further, Ferguson merely discloses "dragging-&-dropping hyperlinks on the interface 246 of the 
invention" (Col. 6, lines 64-65), where such interface 246 is clearly not a button, as shown in 
Figure 8 of Ferguson. Thus, neither Sheldon nor Ferguson, as relied on by the Examiner, meet 
appellant's claimed "bucket [that] includes a button on the toolbar " (emphasis, added), as 
claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "the bucket/portal 
functionality of Sheldon may be incorporated into a button on the toolbar of Sheldon, as Sheldon 
teaches the customization of toolbar buttons as noted above." 

Appellant respectfully disagrees and asserts that Ferguson teaches that " HTTP requests [are] 
issued by dragging-&-dropping hyperlinks on the interface 246 of the invention" (Col. 6, lines 
63-65 - emphasis added), where the interface 246 is "the border 246 of the interface " (Col. 6, 
lines 3-4 - emphasis added). Furthermore, Sheldon teaches that "[w]hen the cursor is positioned 
over the empty area or the header , the user clicks the right mouse button to open the context 
menu 325 . and the context menu 325 appears on the display screen 300" (Col. 14, lines 42-45 - 
emphasis added). Furthermore, Sheldon teaches that "[t]o open the context menu 325, the user 
can either move a cursor (not shown) over. an empty area of the deskbar 310, i.e., where an icon 
or other component cannot be mistakenly selected " (Col. 14, lines 35-38 - emphasis added). 

However, by dragging and dropping hyperlinks on the interface 246, where interface 246 is the 
border 246 of the interface, as in Ferguson, in addition to clicking the header or the empty area. 
where an icon or other component cannot be mistakenly selected, to open the context menu 325, 
as in Sheldon, simply fails to suggest appellant's claimed technique "wherein the bucket includes 
a button on the toolbar " (emphasis added), as claimed by appellant. Clearly, dragging and 
dropping hyperlinks on the empty border 246 of the interface, as in Ferguson, in addition to 
clicking the header or the empty area , where an icon or other component cannot be selected, to 
open the context menu 325, as in Sheldon, simply fails to even suggest a "bucket [that] includes 
a button on the toolbar " (emphasis added), as claimed by appellant. 
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Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art excerpts, as relied upon by the Examiner, fail to 
teach or suggest all of the claim limitations, as noted above. 

Group #4: Claim 41 

With respect to independent Claim 41, the Examiner has relied on Paragraph [0006] in Anuff to 
make a prior art showing of appellant's claimed technique "wherein adding the selected content 
to the portal includes storing the content on the remote server." 

Appellant respectfully notes that the above excerpt relied on by the Examiner merely states that 
"the portal server presents an initial view, or front page, that comprises a plurality of modules 
that are formatted in a predetermined layout," that "[e]ach module represents a resource that can 
be accessed by the user through the portal," and that "[t]he modular nature of the portal enables 
the various resources to be readily and independently updated by the entities who provide them " 
(Paragraph [0006]). 

However, merely disclosing that a portal comprises modules that represent resources accessible 
to the user through the portal, and that the resources may be updated by the entities who provide 
them , as in Anuff, does not disclose a remote server, much less a technique "wherein adding the 
selected content to the portal includes storing the content on the remote server " (emphasis 
added), as specifically claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "the Anuff reference 
indeed teaches a remote server, as can be seen in the client/server architecture of Fig. 3, and at ^ 
0030, and again at Fig. 1, wherein a client using browser 16 connects to servers 12a - 12n 
through network 14 (see \ 0024)." Further, the Examiner has argued that "the Anuff reference 
teaches the storing of content on the remote server, as can be seen through the use of content 
caching on the portal servers, disclosed at 01 02-0 1 04." 
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Appellant respectfully disagrees and asserts that the excerpts from AnufF teach that "by entering 
a particular address in a browser application, the user is presented with one page of information 
that is stored at a particular server " (Paragraph [0024] - emphasis added). Further, the excerpts 
teach that "[t]he functionality associated with the portal is provided bv a portal server , running 
on one or more of the servers 12a-12n," and that "[t]he server consists of process management 
services that are provided bv a web server and suitable class libraries /' where " ftlhese libraries 
connect to other servers and use other resources as needed, including a data store which provides 
object persistence via a suitable database interface" (Paragraph [0030] - emphasis added). 
Additionally, the excerpts teach that " [al portal is supported by an extensible database schema at 
the data storage tier of the overall architecture" (Paragraph [0103] - emphasis added). 

However, teaching that user is presented information stored at a particular server, that the 
functionality associated with the portal is provided bv a portal server, where the server consists 
of process management services that are provided by a web server and suitable class libraries 
that connect to other servers and use other resources as needed, including a data store, as in 
Anuff, simply fails to suggest "adding the selected content to the portal," much less a technique 
"wherein adding the selected content to the portal includes storing the content on the remote 
server" (emphasis added), as specifically claimed. Clearly, presenting information stored at a 
server to a user, as in Anuff, simply fails to even suggest that " adding the selected content to the 
portal includes storing the content on the remote server" (emphasis added), as claimed. 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art excerpts, as relied upon by the Examiner, fail to 
teach or suggest all of the claim limitations, as noted above. 

Issue #2: 

The Examiner has rejected Claims 2, 11, 20, 21, 23-25, 27-29, 31-33, 35, 36, and 38 under 35 
U.S.C. 103(a) as being unpatentable over Ferguson (U.S. Patent No. 6,769,019), in view of 
Sheldon et al. (U.S. Patent No. 6,072,486), in view of Anuff et al. (U.S. Publication No. 
2002/0029296), and in further view of Bascpm et al. (U.S. Patent No. 7,139,974). 
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Group ttl: Claims 20, 21, 23-25, 27-29, 31-33, 35, and 36 

With respect to independent Claims 20, 28, and 36, and particularly appellant's claimed "linking 
the toolbar to a portal of a user," the Examiner has admitted that "Ferguson fails to explicitly 
teach the linking of a portal of a user to a toolbar" 

The Examiner has argued, however, that "Sheldon teaches a system and method for use with web 
browser toolbars, similar to those of Ferguson," and that "Sheldon teaches the ability to 
customize the toolbar of a user interface by adding, deleting, or changing the function of an 
associated button (col. 1, lines 44-48), or further, dragging and dropping components into a 
toolbar or deskbar, as can be seen in col. 19, line 61 through col. 20, line 14, as the user can drag 
an address bar (similar to the bucket of Ferguson, as input is entered into the bar resulting in a 
desired output) into any deskbar." The Examiner has also argued that "Sheldon further states 
that the deskbar may be placed in an application window, such as a web browser, at col. 6, lines 
62-65." The Examiner has thus concluded that "the incorporation of the GUI 246, and its link to 
the displayed portal in Ferguson, is made possible by the toolbar customization of Sheldon." 

Appellant respectfully disagrees and asserts that only generally teaching "toolbars [that] can be 
modified by adding or deleting buttons, or by changing the function associated with a button" 
(Col. 1, lines 44-46), as in Sheldon, fails to even suggest, let alone specifically meet appellant's 
claimed " linking the toolbar to a portal of a user " (emphasis added), as claimed. In addition, 
appellant respectfully points out that Sheldon does not teach that "the user can drag an address 
bar... into any deskbar," as noted by the Examiner. Instead, Sheldon simply discloses that a 
"user can drag and drop a toolbar associated with [an] application window on some other 
area... on the display screen 300," such that "a deskbar is automatically created containing the 
toolbar" (see Col. 20, lines 1-6), which clearly only relates to creating a deskbar that contains a 
selected toolbar. Appellant respectfully asserts that only generally disclosing a technique for 
creating a deskbar that contains a selected toolbar, as in Sheldon, fails to specifically teach 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "Sheldon explicitly 
outlines 'a method for customizing a deskbar', wherein Mf the user desires to customize the 
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taskbar 310 by adding an address bar 600', the use can drag the address toolbar 600 from the 
application window 800' and drop the address bar 600 on top of the taskbar 310/" Further, the 
Examiner has argued that 'Sheldon does indeed teach that 'the user can drag and address 
bar... into any deskbar'." Additionally, the Examiner has stated that "the current citation of 
Sheldon has been expanded to cover col. 20, lines 15-41, where previously the examiner closed 
the citation at col. 20, line 14." 

Appellant respectfully disagrees and asserts that Sheldon merely teaches that "[i]n FIG. 20a, if 
the user desires to customize the taskbar 310 by adding an address toolbar 600 \ the user can drag 
the address toolbar 600 from the application window 800' and drop the address toolbar 600 on 
top of the taskbar 310 " such that " Ftlhe address toolbar 600 is copied during the dragging 
process " (Col. 20, lines 25-3 1 - emphasis added). 

However, teaching that the user can drag the address toolbar from the application window and 
drop the address toolbar on top of the taskbar to customize the taskbar by adding an address 
toolbar , where the address toolbar is copied during the dragging process , as in Sheldon, fails to 
suggest " linking the toolbar to a portal of a user" (emphasis added), as claimed. Clearly, 
copying the address toolbar during the dragging process and customizing the taskbar by adding 
an address toolbar , as in Sheldon, simply fails to even suggest " linking the toolbar to a portal of 
a user" (emphasis added), as claimed. 

Still yet, Sheldon's disclosure of a "deskbar [that] may simultaneously contain toolbars and 
toolbar components..., and [that] may exist in an application window" (Col. 6, lines 62-65), as 
referenced by the Examiner, only suggests allowing a deskbar to exist in an application window. 
which does meet appellant's claimed " linking the toolbar to a portal of a user" (emphasis added), 
as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "as in previous 
Office actions,... incorporation of the 'bucket' of Ferguson into the customizable toolbar of 
Sheldon links the toolbar to the portal, as the bucket provides a direct link to the portal." 
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First, appellant respectfully disagrees and again asserts that Sheldon's disclosure of a "deskbar 
[that] may simultaneously contain toolbars and toolbar components..., and [that] may exist in an 
application window" (Col. 6, lines 62-65), as referenced by the Examiner, only suggests 
allowing a deskbar to exist in an a pplication window , which does not meet appellant's claimed 
' linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Further, appellant respectfully asserts that Ferguson teaches that "[i]n the case of any secondary 
request being initiated by the user dragging-&-dropping a hyperlink from a Web page , the 
invention generates the appropriate HTTP request, fetches the data from the requested Web 
server 10, and archives the information in a cache on the user's hard drive 36" (Col. 7, lines 9-14 
- emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user desires to 
customize the taskbar 310 by adding an address toolbar 600 *. the user can drag the address 
toolbar 600 from the application window 800' and drop the address toolbar 600 on top of the 
taskbar 310 " such that u [t]he address toolbar 600 is copied during the dragging process " (Col. 
20, lines 25-3 1 - emphasis added). 

However, dragging-&-dropping a hyperlink from a Web page, fetching the data from the 
requested Web server, and archiving the information in a cache on the user's hard drive, as in 
Ferguson, in addition to dragging the address toolbar from the application window and dro pping 
the address toolbar on top of the taskbar to customize the taskbar by adding an address toolbar. 
where the address toolbar is copied during the dragging process, as in Sheldon, fails to suggest 
' linking the toolbar to a portal of a user" (emphasis added), as claimed. Clearly, fetching data 
and archiving the information, as in Ferguson, in addition to customizing the taskbar by adding 
an address toolbar and copying the address toolbar during the dragging process, as in Sheldon, 
simply fails to suggest any sort of "linking," much less " linking the toolbar to a portal of a user" 
(emphasis added), as claimed. 

Moreover, appellant respectfully disagrees with the Examiner's argument that "incorporation of 
the GUI 246, and its link to the displayed portal in Ferguson, is made possible by the toolbar 
customization of Sheldon." Appellant respectfully notes that the Examiner has expressly relied 
on the GUI 246 in Ferguson to meet appellant's claimed portal, as expressed by the Examiner's 
statement that "the open GUI [is] analogous to the claimed 'portal'" (see Page 2 of the Office 
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Action). Since the Examiner has relied on the GUI 246 in Ferguson to meet appellant's claimed 
portal , such GUI clearly cannot have a " link to the displayed portal in Ferguson" (emphasis 
added), as noted by the Examiner. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "[a]ppellant... [has] 
misinterpreted the rejection of the claims with respect to the GUI 246 of Ferguson and the 
claimed portal" and that "GUI 246... teachjes] the claimed 'bucket', not the claimed 'portal', as 
argued by [a]ppellant " Further, the Examiner has argued that "[t]his distinction is highlighted 
by Figs. 7 and 8 of Ferguson" where "Fig. 7 depicts the 'bucket' as referred to by the examiner." 
Additionally, the Examiner has argued that "the user drags links into the GUI 246, the links then 
being added to the 'portal', interpreted by the [E]xaminer as the list of links selected by the user 
in item 261 of Fig. 8." In addition, the Examiner has argued that "[t]he 'open GUP referred to 
by the [E]xaminer is not simply GUI 246, but instead the expanded GUI of Fig. 8, and more 
specifically, the list of links 261 " 

Appellant respectfully disagrees and asserts that Ferguson teaches that u [t]he O-Links list display 
261 is depicted in FIG. 8" such that "[w]hen the user opens the maximized graphical user 
interface (GUI) 251, this invokes the Q-Links Manager, as depicted in the flowchart FIG. 20 at 
164," and that "[i]n step 166, the invention obtains the O-Links list and displays it on the 
maximized GUI 251 in step 168" (Col. 30, line 66-Col. 31, line 4 - emphasis added). Further, 
Ferguson teaches that "[i]f the user left clicks (or equivalent), on the link name or Web address 
of the O-Link which appears in the O-Links display list 261 that he/she wishes to view in the 
browser 62, the invention returns with that page from the invention's hard disk Cache 420" (Col. 
31, lines 39-45 - emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user 
desires to customize the taskbar 310 bv adding an address toolbar 600 *. the user can drag the 
address toolbar 600 from the application window 800' and drop the address toolbar 600 on top of 
the taskbar 310 " such that " f tlhe address toolbar 600 is copied during the dragging process" (Col: 
20, lines 25-3 1 - emphasis added). 

However, teaching a O-Link . which appears in the O-Links display list 261 . as in Ferguson, in 
addition to dragging the address toolbar from the application window and dro pping the address 
toolbar on top of the taskbar, where the address toolbar is copied during the dragging process, as 
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in Sheldon, simply fails to suggest " linking the toolbar to a portal of a user" (emphasis added), 
as claimed. Clearly, a Q-Link a ppearing in the OLinks display list 261, as in Ferguson, in 
addition to dropping the address toolbar on top of the taskbar, as in Sheldon, simply fails to even 
suggest " linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Additionally, it appears that the Examiner has relied on an inherency argument regarding the 
above emphasized claim limitations. In view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific prior 
art showing of such claim features, in combination with the remaining claim elements is 
respectfully requested. (See MPEP 2112) 

Further, in response, appellant asserts that the fact that a certain result or characteristic may 
occur or be present in the prior art is not sufficient to establish the inherency of that result or 
characteristic. In re Rijckaert, 9 F.3d 1531, 1534, 28 USPQ2d 1955, 1957 (Fed. Cir. 1993); In re 
Oelrich, 666 F.2d 578, 581-82, 212 USPQ 323, 326 (CCPA 1981). "To establish inherency, the 
extrinsic evidence 'must make clear that the missing descriptive matter is necessarily present in 
the thing described in the reference, and that it would be so recognized by persons of ordinary 
skill. Inherency, however, may not be established by probabilities or possibilities. The mere fact 
that a certain thing may result from a given set of circumstances is not sufficient."' In re 
Robertson, 169 F.3d 743, 745, 49 USPQ2d 1949, 1950-51 (Fed. Cir. 1999). 

Still yet, the Examiner has argued that "[a]s the bucket of Ferguson is linked to the user portal, 
any incorporation of the bucket into a toolbar (as done by Sheldon) therefore links the toolbar to 
the user- portal." 

Appellant respectfully disagrees and again points out that Sheldon merely discloses that a "user 
can drag and drop a toolbar associated with [an] application window on some other area... on the 
display screen 300," such that "a deskbar is automatically created containing the toolbar" (see 
Col. 20, lines 1-6), which clearly only relates to creating a deskbar that contains a selected 
toolbar. Appellant respectfully asserts that merely allowing a user to drag and drop a toolbar on 
some area of a display screen, where a deskbar containing the toolbar is created, as in Sheldon, 
fails to support the Examiner's allegation that Sheldon teaches "incorporation of the bucket into 
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a toolbar " (emphasis added). To this end, the excerpts from Ferguson and Sheldon, as relied on 
by the Examiner, do not meet "linking the toolbar to a portal of a user," as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "the combination of 
the bucket and portal of Ferguson into the customizable toolbars of Sheldon would indeed 
necessarily provide a link from the toolbar to the portal of a user." Further, the Examiner has 
argued that "Sheldon has been shown to teach a link between a bucket and a portal, as indicated 
by the ability of a user to drag and drop links into the bucket GUI 246, the links then being 
shown in the portal list 261." In addition, the Examiner has argued that "it [is believed] to be 
inherent that adding the bucket/portal functionality of Ferguson into the toolbar of Sheldon 
would indeed provide a link from the toolbar to the portal, and is not 'established by probabilities 
or possibilities'." 

Appellant respectfully disagrees and asserts that Ferguson teaches that " HTTP requests [are] 
issued by dragging-&-dropping hyperlinks on the interface 246 of the invention" (Col. 6, lines 
63-65 - emphasis added). Further, Ferguson teaches that "[i]n the case of any secondary request 
being initiated by the user dragging-&-dropping a hyperlink from a Web page, the invention 
generates the appropriate HTTP request, fetches the data from the requested Web server 10, and 
archives the information in a cache on the user's hard drive 36" such that "[u]pon receiving page 
requests from the list of links downloaded in the background (known as O-Links ). the files 
associated with the request are retrieved from the 1 local hard drive cache' " (Col. 7, lines 9-20 - 
emphasis added). Furthermore, Sheldon teaches that u [i]n FIG. 20a, if the user desires to 
customize the taskbar 310 by adding an address toolbar 600 \ the user can drag the address 
toolbar 600 from the application window 800' and drop the address toolbar 600 on top of the 
taskbar 310 " such that " ftlhe address toolbar 600 is copied during the dragging process " (Col. 
20, lines 25-3 1 - emphasis added). 

However, dragging-&-dropping hyperlinks on the interface 246, generating the appropriate 
HTTP request , fetching the data from the requested Web server 10, and archiving the 
information in a cache on the user's hard drive 36, where the files associated with the request are 
retrieved from the c local hard drive cache' upon receiving page requests from the list of links (Q- 
Links), as in Ferguson, in addition dragging and dropping the address toolbar 600 on top of the 
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taskbar 3 1 0 in order to customize the taskbar by adding an address toolbar 600 . as in Sheldon, 
simply fails to suggest "linking the toolbar to a portal of a user" (emphasis added), as claimed. 
Clearly, adding the address toolbar to the taskbar by dragging and dropping , as in Sheldon, in 
addition to dragging and dropping hyperlinks on the interface 246 to generate a HTTP request, 
fetch the data, and archive the information in a cache, as Ferguson, simply fails to even suggest 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Furthermore, Sheldon teaches that "[t]he address toolbar allows the user to enter a Web address 
to open a Web page without having to open the web browser application program 37 (FIG. 1)" 
(Col. 14, lines 58-60 - emphasis added). However, adding the address toolbar to the taskbar, 
which allows the user to enter a Web address to open a Web page without having to open the 
web browser, as in Sheldon, simply fails to even suggest " linking the toolbar to a portal of a 
user" (emphasis added), as claimed. Clearly, adding an address toolbar that allows the user to 
open a Web page, as in Sheldon, in addition to dragging and dropping hyperlinks on the interface 
246, generating the HTTP request, fetching the data, and archiving the information in a cache, as 
in Ferguson, simply fails to even suggest "linking the toolbar to a portal of a user" (emphasis 
added), as claimed. 

Appellant respectfully asserts that in view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific prior 
art showing of such claim features, in combination with the remaining claim elements is 
respectfully requested. (See MPEP 21 12) 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art excerpts, as relied upon by the Examiner, fail to 
teach or suggest aU of the claim limitations, as noted above. 

Group U2: Claims 2 and II 

With respect to dependent Claim 2 et al., the Examiner has again relied on Col. 21, lines 3-6 
from the Bascom reference to make a prior art showing of appellant's claimed "toolbar [that] 
includes a sign on button, wherein the toolbar links to the portal upon the user signing in." 
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Specifically, the Examiner has argued that "Bascom teaches the use of sign on buttons in a web 
browser toolbar to allow access to secure information." 

First, appellant respectfully asserts that merely allowing access to secure information, as noted 
by the Examiner, fails to rise to the level of specificity of appellant's claimed " toolbar [that] 
links to the portal upon the user signing in" (emphasis added), as claimed. Second, appellant 
respectfully asserts that the excerpt from Bascom relied on by the Examiner only generally 
discloses that a "client logon button 1050 initiates a connection between the client tool 220 and 
one or more servers 30." Appellant notes that such excerpt further teaches that "[t]he client 
toolbar 1010 includes a number of GUI buttons that initiate various functions of the client tool 
220" (emphasis added). Clearly, Bascom only discloses connecting a client tool to a server, and 
not a " toolbar [that] links to the portal upon the user signing in" (emphasis added), as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "[a]s shown above, 
Ferguson and Sheldon teach a toolbar capable of providing a link to a portal" and that "Anuff has 
been shown to provide a remote server capable of storing portal data accessed by a client." 
Further, the Examiner has argued that "Bascom teaches a client logon button that allows a client 
to initiate connection to one or more servers." Additionally, the Examiner has argued that "the 
logon button of the Bascom reference is capable of initiating connection to the portal servers of 
Anuff, which in turn provides access to the portal linked to through the toolbar of Ferguson and 
Sheldon." 

Appellant respectfully disagrees and asserts that Ferguson teaches that "HTTP requests Farel 
issued by dragging-&-dropping hyperlinks on the interface 246 of the invention" (Col. 6, lines 
63-65 - emphasis added), where the interface 246 is "the border 246 of the [maximized graphical 
userl interface [2511 " (Col. 6, lines 3-4 - emphasis added) and that "[t]he maximized GUI ... 251 
displays a list 261 of the Q-Link and Q-Touch content to be downloaded, downloading, or 
downloaded in the background" (Col. 6, lines 30-32 - emphasis added). Further, Ferguson 
teaches that "[i]n the case of any secondary request being initiated by the user dragging-&- 
dro pping a hyperlink from a Web page , the invention generates the appropriate HTTP request, 
fetches the data from the requested Web server 10, and archives the information in a cache on the 
user's hard drive 36" (Col. 7, lines 9-14 - emphasis added). Additionally, Sheldon teaches that 
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"[i]n FIG. 20a, if the user desires to customize the taskbar 310 by adding an address toolbar 600 ', 
the user can drag the address toolbar 600 from the application window 800 ! and drop the address 
toolbar 600 on top of the taskbar 310 " such that " |t]he address toolbar 600 is copied during the 
dragging process " (Col. 20, lines 25-31 - emphasis added) and that "[t]he address toolbar allows 
the user to enter a Web address to open a Web cage without having to open the web browser 
application program 37 (FIG. 1)" (Col. 14, lines 58-60 - emphasis added). Still yet, Bascom 
teaches a " client logon button 1050 initiates a connection between the client tool 220 and one or 
more servers 30" (Col. 21, lines 4-6 - emphasis added). 

However, dragging and dropping the address toolbar on top of the taskbar to add the address 
toolbar to the taskbar , which allows the user to enter a Web address to open a Web page without 
having to open the web browser, as in Sheldon, dragging and dropping a hyperlink from a Web 
page on border 246 of the maximized GUI 251 to generate the HTTP request, fetch the data from 
the Web server, and archive the information in a cache on the user's hard drive , where the 
maximized GUI 25 1 displays a list 261 of content, as in Ferguson, in addition to a client logon 
button initiating a connection between the client tool and the servers , as in Bascom, fails to 
suggest a " toolbar [that] links to the portal upon the user signing in" (emphasis added), as 
claimed. 

Clearly, dragging and dropping the address toolbar to add the address toolbar to the taskbar, as in 
Sheldon, dragging and dropping a hyperlink from a Web page on border 246 of the maximized 
GUI 251 to generate a HTTP request, fetch data, and archive information in a cache on a user's 
hard drive , where the maximized GUI 251 displays the list 26 K as in Ferguson, in addition to a 
client logon button that initiates a connection between the client tool and the servers , as in 
Bascom, simply fails to even suggest a " toolbar [that] links to the portal upon the user signing 
in" (emphasis added), as claimed. 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art excerpts, as relied upon by the Examiner, fail to 
teach or suggest aU of the claim limitations, as noted above. 

Group #3: Claim 38 
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With respect to independent Claim 38, and particularly appellant's claimed "linking the toolbar 
to a portal of a user," the Examiner has admitted that "Ferguson fails to explicitly teach the 
linking of a portal of a user to a toolbar." 

The Examiner has argued, however, that "Sheldon teaches a system and method for use with web 
browser toolbars, similar to those of Ferguson," and that "Sheldon teaches the ability to 
customize the toolbar of a user interface by adding, deleting, or changing the function of an 
associated button (col. 1, lines 44-48), or further, dragging and dropping components into a 
toolbar or deskbar, as can be seen in col. 19, line 61 through col. 20, line 14, as the user can drag 
an address bar (similar to the bucket of Ferguson, as input is entered into the bar resulting in a 
desired output) into any deskbar." The Examiner has also argued that "Sheldon further states 
that the deskbar may be placed in an application window, such as a web browser, at col, 6, lines 
62-65 " The Examiner has thus concluded that "the incorporation of the GUI 246, and its link to 
the displayed portal in Ferguson, is made possible by the toolbar customization of Sheldon." 

Appellant respectfully disagrees and asserts that only generally teaching "toolbars [that] can be 
modified by adding or deleting buttons, or by changing the function associated with a button" 
(Col. 1, lines 44-46), as in Sheldon, fails to even suggest, let alone specifically meet appellant's 
claimed " linking the toolbar to a portal of a user " (emphasis added), as claimed. In addition, 
appellant respectfully points out that Sheldon does not teach that "the user can drag an address 
bar... into any deskbar," as noted by the Examiner, Instead, Sheldon simply discloses that a 
"user can drag and drop a toolbar associated with [an] application window on some other 
area... on the display screen 300," such that "a deskbar is automatically created containing the 
toolbar" (see Col. 20, lines 1-6), which clearly only relates to creating a deskbar that contains a 
selected toolbar. Appellant respectfully asserts that only generally disclosing a technique for 
creating a deskbar that contains a selected toolbar, as in Sheldon, fails to specifically teach 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "Sheldon explicitly 
outlines 'a method for customizing a deskbar', wherein 'if the user desires to customize the 
taskbar 310 by adding an address bar 600\ the use can drag the address toolbar 600 from the 
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application window 800' and drop the address bar 600 on top of the taskbar 310.'" Further, the 
Examiner has argued that 'Sheldon does indeed teach that 'the user can drag and address 
bar... into any deskbar'." Additionally, the Examiner has stated that "the current citation of 
Sheldon has been expanded to cover col. 20, lines 15-41, where previously the examiner closed 
the citation at col. 20, line 14." 

Appellant respectfully disagrees and asserts that Sheldon merely teaches that "[i]n FIG. 20a, if 
the user desires to customize the taskbar 310 by adding an address toolbar 600 1 . the user can drag 
the address toolbar 600 from the application window 800* and drop the address toolbar 600 on 
top of the taskbar 310 " such that " [t]he address toolbar 600 is copied during the dragging 
process " (Col. 20, lines 25-3 1 - emphasis added). 

However, teaching that the user can drag the address toolbar from the application window and 
drop the address toolbar on top of the taskbar to customize the taskbar bv adding an address 
toolbar , where the address toolbar is copied during the dragging process , as in Sheldon, fails to 
suggest "linking the toolbar to a portal of a user" (emphasis added), as claimed. Clearly, 
copying the address toolbar during the dragging process and customizing the taskbar by adding 
an address toolbar , as in Sheldon, simply fails to even suggest "linking the toolbar to a portal of 
a user" (emphasis added), as claimed. 

Still yet, Sheldon's disclosure of a "deskbar [that] may simultaneously contain toolbars and 
toolbar components..., and [that] may exist in an application window" (Col. 6, lines 62-65), as 
referenced by the Examiner, only suggests allowing a deskbar to exist in an a pplication window, 
which does meet appellant's claimed " linking the toolbar to a portal of a user" (emphasis added), 
as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "as in previous 
Office actions,... incorporation of the 'bucket' of Ferguson into the customizable toolbar of 
Sheldon links the toolbar to the portal, as the bucket provides a direct link to the portal." 

First, appellant respectfully disagrees and again asserts that Sheldon's disclosure of a "deskbar 
[that] may simultaneously contain toolbars and toolbar components..., and [that] may exist in an 
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application window" (Col. 6, lines 62-65), as referenced by the Examiner, only suggests 
allowing a deskbar to exist in an a pplication window , which does not meet appellant's claimed 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Further, appellant respectfully asserts that Ferguson teaches that "[i]n the case of any secondary 
request being initiated by the user dragging-&-dropping a hyperlink from a Web page , the 
invention generates the appropriate HTTP request, fetches the data from the requested Web 
server 10, and archives the information in a cache on the user's hard drive 36" (Col. 7, lines 9-14 
- emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user desires to 
customize the taskbar 310 by adding an address toolbar 600 '. .the user can drag the address 
toolbar 600 from the application window 800' and drop the address toolbar 600 on top of the 
taskbar 310 " such that " ftlhe address toolbar 600 is copied during the dragging process " (Col. 
20, lines 25-3 1 - emphasis added). 

However, dragging-&-dropping a hyperlink from a Web page, fetching the data from the 
requested Web server, and archiving the information in a cache on the user's hard drive, as in 
Ferguson, in addition to dragging the address toolbar from the application window and dro pping 
the address toolbar on top of the taskbar to customize the taskbar by adding an address toolbar , 
where the address toolbar is copied during the dragging process, as in Sheldon, fails to suggest 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. Clearly, fetching data 
and archiving the information, as in Ferguson, in addition to customizing the taskbar by adding 
an address toolbar and copying the address toolbar during the dragging process, as in Sheldon, 
simply fails to suggest any sort of "linking," much less " linking the toolbar to a portal of a user" 
(emphasis added), as claimed. 

Moreover, appellant respectfully disagrees with the Examiner's argument that "incorporation of 
the GUI 246, and its link to the displayed portal in Ferguson, is made possible by the toolbar 
customization of Sheldon." Appellant respectfully notes that the Examiner has expressly relied 
on the GUI 246 in Ferguson to meet appellant's claimed portal, as expressed by the Examiner's 
statement that "the open GUI [is] analogous to the claimed 'portal'" (see Page 2 of the Office 
Action). Since the Examiner has relied on the GUI 246 in Ferguson to meet appellant's claimed 
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portal, such GUI clearly cannot have a ' Mink to the displayed portal in Ferguson" (emphasis 
added), as noted by the Examiner. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "[a]ppellant... [has] 
misinterpreted the rejection of the claims with respect to the GUI 246 of Ferguson and the 
claimed portal" and that "GUI 246... teach[es] the claimed 'bucket', not the claimed 'portal', as 
argued by [a]ppellant." Further, the Examiner has argued that "[t]his distinction is highlighted 
by Figs. 7 and 8 of Ferguson" where "Fig. 7 depicts the 'bucket' as referred to by the examiner." 
Additionally, the Examiner has argued that "the user drags links into the GUI 246, the links then 
being added to the 'portal', interpreted by the [E]xaminer as the list of links selected by the user 
in item 261 of Fig. 8." In addition, the Examiner has argued that "[t]he 'open GUP referred to 
by the [EJxaminer is not simply GUI 246, but instead the expanded GUI of Fig. 8, and more 
specifically, the list of links 261." 

Appellant respectfully disagrees and asserts that Ferguson teaches that " [t]he O-Links list display 
261 is depicted in FIG. 8" such that "[w]hen the user opens the maximized graphical user 
interface (GUI) 251, this invokes the Q-Links Manager, as depicted in the flowchart FIG. 20 at 
164," and that "[i]n step 166, the invention obtains the O-Links list and displays it on the 
maximized GUI 251 in step 168" (Col. 30, line 66-Col. 31, line 4 - emphasis added). Further, 
Ferguson teaches that "[i]f the user left clicks (or equivalent), on the link name or Web address 
of the O-Link which appears in the Q-Links display list 261 that he/she wishes to view in the 
browser 62, the invention returns with that page from the invention's hard disk Cache 420" (Col. 
31, lines 39-45 - emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user 
desires to customize the taskbar 310 by adding an address toolbar 600 ', the user can drag the 
address toolbar 600 from the application window 800' and drop the address toolbar 600 on top of 
the taskbar 3 10 " such that " ftlhe address toolbar 600 is copied during the dragging process" (Col, 
20, lines 25-3 1 - emphasis added). 

However, teaching a O-Link , which appears in the O-Links display list 261 , as in Ferguson, in 
addition to dragging the address toolbar from the application window and dropping the address 
toolbar on top of the taskbar, where the address toolbar is copied during the dragging process, as 
in Sheldon, simply fails to suggest " linking the toolbar to a portal of a user" (emphasis added), 
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as claimed. Clearly, a Q-Link a ppearing in the O-Links display list 261, as in Ferguson, in 
addition to dropping the address toolbar on top of the taskbar. as in Sheldon, simply fails to even 
suggest " linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Additionally, it appears that the Examiner has relied on an inherency argument regarding the 
above emphasized claim limitations. In view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific prior 
art showing of such claim features, in combination with the remaining claim elements is 
respectfully requested. (See MPEP 21 12) 

Further, in response, appellant asserts that the fact that a certain result or characteristic may 
occur or be present in the prior art is not sufficient to establish the inherency of that result or 
characteristic. In re Rijckaert, 9 F.3d 1531, 1534, 28 USPQ2d 1955, 1957 (Fed. Cir. 1993); In re 
Oelrich, 666 F.2d 578, 581-82, 212 USPQ 323, 326 (CCPA 1981). "To establish inherency, the 
extrinsic evidence 'must make clear that the missing descriptive matter is necessarily present in 
the thing described in the reference, and that it would be so recognized by persons of ordinary 
skill. Inherency, however, may not be established by probabilities or possibilities. The mere fact 
that a certain thing may result from a given set of circumstances is not sufficient/" In re 
Robertson, 169 F.3d 743, 745, 49 USPQ2d 1949, 1950-51 (Fed. Cir. 1999). 

Still yet, the Examiner has argued that "[a]s the bucket of Ferguson is linked to the user portal, 
any incorporation of the bucket into a toolbar (as done by Sheldon) therefore links the toolbar to 
the user portal." 

Appellant respectfully disagrees and again points out that Sheldon merely discloses that a "user 
can drag and drop a toolbar associated with [an] application window on some other area... on the 
display screen 300," such that "a deskbar is automatically created containing the toolbar" (see 
Col. 20, lines 1-6), which clearly only relates to creating a deskbar that contains a selected 
toolbar. Appellant respectfully asserts that merely allowing a user to drag and drop a toolbar on 
some area of a display screen, where a deskbar containing the toolbar is created, as in Sheldon, 
fails to support the Examiner's allegation that Sheldon teaches "incorporation of the bucket into 
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a toolbar " (emphasis added). To this end, the excerpts from Ferguson and Sheldon, as relied on 
by the Examiner, do not meet "linking the toolbar to a portal of a user," as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "the combination of 
the bucket and portal of Ferguson into the customizable toolbars of Sheldon would indeed 
necessarily provide a link from the toolbar to the portal of a user." Further, the Examiner has 
argued that "Sheldon has been shown to teach a link between a bucket and a portal, as indicated 
by the ability of a user to drag and drop links into the bucket GUI 246, the links then being 
shown in the portal list 261." In addition, the Examiner has argued that "it [is believed] to be 
inherent that adding the bucket/portal functionality of Ferguson into the toolbar of Sheldon 
would indeed provide a link from the toolbar to the portal, and is not 'established by probabilities 
or possibilities'." 

Appellant respectfully disagrees and asserts that Ferguson teaches that "HTTP requests farel 
issued by dragging-&-dropping hyperlinks on the interface 246 of the invention" (Col. 6, lines 
63-65 - emphasis added). Further, Ferguson teaches that "[i]n the case of any secondary request 
being initiated by the user dragging-&-dropping a hyperlink from a Web page , the invention 
generates the appropriate HTTP request, fetches the data from the requested Web server 10, and 
archives the information in a cache on the user's hard drive 36" such that "[u]pon receiving page 
requests from the list of links downloaded in the background (known as O-Links ). the files 
associated with the request are retrieved from the 'local hard drive cache' " (Col. 7, lines 9-20 - 
emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user desires to 
customize the taskbar 310 bv adding an address toolbar 600 ', the user can drag the address 
toolbar 600 from the application window 800' and drop the address toolbar 600 on top of the 
taskbar 310" such that " ftlhe address toolbar 600 is copied during the dragging process " (Col. 
20, lines 25-3 1 - emphasis added). 

However, dragging-&-dropping hyperlinks on the interface 246, generating the appropriate 
HTTP request , fetching the data from the requested Web server 10, and archiving the 
information in a cache on the user's hard drive 36, where the files associated with the request are 
retrieved from the 'local hard drive cache' upon receiving page requests from the list of links (Q- 
Links), as in Ferguson, in addition dragging and dropping the address toolbar 600 on top of the 



30 



taskbar 3 1 0 in order to customize the taskbar by adding an address toolbar 600 . as in Sheldon, 
simply fails to suggest " Unking the toolbar to a portal of a user" (emphasis added), as claimed. 
Clearly, adding the address toolbar to the taskbar by dragging and dropping , as in Sheldon, in 
addition to dragging and dropping hyperlinks on the interface 246 to generate a HTTP request, 
fetch the data, and archive the information in a cache, as Ferguson, simply fails to even suggest 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Furthermore, Sheldon teaches that "[t]he address toolbar allows the user to enter a Web address 
to open a Web page without having to open the web browser application program 37 (FIG. 1)" 
(Col. 14, lines 58-60 - emphasis added). However, adding the address toolbar to the taskbar, 
which allows the user to enter a Web address to open a Web page without having to open the 
web browser, as in Sheldon, simply fails to even suggest " linking the toolbar to a portal of a 
user" (emphasis added), as claimed. Clearly, adding an address toolbar that allows the user to 
open a Web page, as in Sheldon, in addition to dragging and dropping hyperlinks on the interface 
246, generating the HTTP request, fetching the data, and archiving the information in a cache, as 
in Ferguson, simply fails to even suggest " linking the toolbar to a portal of a user" (emphasis 
added), as claimed. 

Appellant respectfully asserts that in view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific prior 
art showing of such claim features, in combination with the remaining claim elements is 
respectfully requested. (See MPEP 2112) 

Further, with respect to independent Claim 38, appellant notes the Examiner has relied on Col. 
21, lines 3-6 from the Bascom reference to make a prior art showing of appellant's claimed 
"linking the toolbar to a portal of the user on a remote server coupled to the computer via 
network upon the user signing on." Specifically, the Examiner has argued that "Bascom teaches 
the use of sign on buttons in a web browser toolbar to allow access to secure information." 

First, appellant respectfully asserts that merely allowing access to secure information, as noted 
by the Examiner, fails to rise to the level of specificity of appellant's claimed " linking the 
toolbar to a portal of the user on a remote server coupled to the computer via network upon the 
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user signing on " (emphasis added), as claimed. Second, appellant respectfully asserts that the 
excerpt from Bascom relied on by the Examiner only generally discloses that a "client logon 
button 1050 initiates a connection between the client tool 220 and one or more servers 30." 
Appellant notes that such excerpt further teaches that "[t]he client toolbar 1010 includes a 
number of GUI buttons that initiate various functions of the client tool 220" (emphasis added). 
Clearly, Bascom only discloses connecting a client tool to a server, and not "linking the toolbar 
to a portal of the user. ..upon the user signing on" (emphasis added), as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "[a]s shown above, 
Ferguson and Sheldon teach a toolbar capable of providing a link to a portal" and that "Anuff has 
been shown to provide a remote server capable of storing portal data accessed by a client." 
Further, the Examiner has argued that "Bascom teaches a client logon button that allows a client 
to initiate connection to one or more servers." Additionally, the Examiner has argued that "the 
logon button of the Bascom reference is capable of initiating connection to the portal servers of 
Anuff, which in turn provides access to the portal linked to through the toolbar of Ferguson and 
Sheldon." 

Appellant respectfully disagrees and asserts that Ferguson teaches that "HTTP requests Tarel 
issued by dragging-&-dropping hyperlinks on the interface 246 of the invention" (Col. 6, lines 
63-65 - emphasis added), where the interface 246 is "the border 246 of the [maximized graphical 
userl interface f2511 " (Col. 6, lines 3-4 - emphasis added) and that "[t]he maximized GUI ... 251 
displays a list 261 of the Q-Link and Q-Touch content to be downloaded, downloading, or 
downloaded in the background" (Col. 6, lines 30-32 - emphasis added). Further, Ferguson 
teaches that "[i]n the case of any secondary request being initiated by the user dragging-&- 
drooping a hyperlink from a Web page , the invention generates the appropriate HTTP request, 
fetches the data from the requested Web server 10, and archives the information in a cache on the 
user's hard drive 36" (Col. 7, lines 9-14 - emphasis added). Additionally, Sheldon teaches that 
"[i]n FIG. 20a, if the user desires to customize the taskbar 310 bv adding an address toolbar 600 \ 
the user can drag the address toolbar 600 from the application window 800 1 and drop the address 
toolbar 600 on top of the taskbar 310 " such that " |Y[he address toolbar 600 is copied during the 
dragging process " (Col. 20, lines 25-3 1 - emphasis added) and that "[t]he address toolbar allows 
the user to enter a Web address to open a Web page without having to open the web browser 
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application program 37 (FIG. 1)" (Col. 14, lines 58-60 - emphasis added). Still yet, Bascom 
teaches a " client logon button 1050 initiates a connection between the client tool 220 and one or 
more servers 30" (Col. 2 1 , lines 4-6 - emphasis added). 

However, dragging and dropping the address toolbar on top of the taskbar to add the address 
toolbar to the taskbar . which allows the user to enter a Web address to open a Web page without 
having to open the web browser, as in Sheldon, dragging and dropping a hyperlink from a Web 
page on border 246 of the maximized GUI 251 to generate the HTTP request, fetch the data from 
the Web server, and archive the information in a cache on the user's hard drive , where the 
maximized GUI 251 displays a list 261 of content, as in Ferguson, in addition to a client logon 
button initiating a connection between the client tool and the servers , as in Bascom, fails to 
suggest " linking the toolbar to a portal of the user. . . upon the user signing on" (emphasis added), 
as claimed. 

Clearly, dragging and dropping the address toolbar to add the address toolbar to the taskbar, as in 
Sheldon, dragging and dropping a hyperlink from a Web page on border 246 of the maximized 
GUI 251 to generate a HTTP request, fetch data, and archive information in a cache on a user's 
hard drive , where the maximized GUI 25 1 displays the list 261. as in Ferguson, in addition to a 
client logon button that initiates a connection between the client tool and the servers , as in 
Bascom, simply fails to even suggest " linking the toolbar to a portal of the user... upon the user 
signing on " (emphasis added), as claimed. 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art excerpts, as relied upon by the Examiner, fail to 
teach or suggest all of the claim limitations, as noted above. 

Issue # 3: 

The Examiner has rejected Claims 4 and 13 under 35 U.S.C. 103(a) as being unpatentable over 
Ferguson (U.S. Patent No. 6,769,019), in view of Sheldon et al. (U.S. Patent No. 6,072,486), in 
view of Anuff et al. (U.S. Publication No. 2002/0029296), and in further view of Schultz et al. 
(U.S. Patent No. 6,453,339). 
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Group til: Claims 4 and 13 

Appellant respectfully asserts that such claims are not met by the prior art for the reasons argued 
with respect to Issue #1; Group #1. 

Issue # 4: 

The Examiner has rejected Claims 22 and 30 under 35 U.S.C. 103(a) as being unpatentable over 
Ferguson (U.S. Patent No. 6,769,019), in view of Sheldon et al. (U.S. Patent No. 6,072,486), in 
view of Anuff et al. (U.S. Publication No. 2002/0029296), in view of Bascom et al. (U.S. Patent 
No. 7, 1 39,974), and in further view of Schultz et al. (U.S. Patent No. 6,453,339). 

Group #1: Claims 22 and 30 

Appellant respectfully asserts that such claims are not met by the prior art for the reasons argued 
with respect to Issue #2, Group #1. 

Issue # 5: 

The Examiner has rejected Claims 8 and 17 under 35 U.S.C. 103(a) as being unpatentable over 
Ferguson (U.S. Patent No. 6,769,019), in view of Sheldon et al. (U.S. Patent No. 6,072,486), in 
view of Anuff et al. (U.S. Publication No. 2002/0029296), and in further view of Shafiron (U.S. 
Patent Publication No. 2004/0165007). 

Group til: Claims 8 and 1 7 

Appellant respectfully asserts that such claims are not met by the prior art for the reasons argued 
with respect to Issue #1, Group #1. 



Issue # 6: 
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The Examiner has rejected Claims 26 and 34 under 35 U.S.C. 103(a) as being unpatentable over 
Ferguson (U.S. Patent No. 6,769,019), in view of Sheldon et al. (U.S. Patent No. -6,072,486), in 
view of Anuff et al. (U.S. Publication No. 2002/0029296), in view of Bascom et al. (U.S. Patent 
No. 7,139,974), and in further view of Shafron (U.S. Patent Publication No. 2004/0165007). 

Group #1: Claims 26 and 34 

Appellant respectfully asserts that such claims are not met by the prior art for the reasons argued 
with respect to Issue #2, Group #1 . 

Issue # 7: 

The Examiner has rejected Claim 37 under 35 U.S.C. 103(a) as being unpatentable over 
Ferguson (U.S. Patent No. 6,769,019), in view of Sheldon et al. (U.S. Patent No. 6,072,486), in 
view of Anuff et al. (U.S. Publication No. 2002/0029296), in view of Bascom et al. (U.S. Patent 
No. 7,139,974), in view of Shafron (U.S. Patent Publication No. 2004/0165007), and in further 
view of Schultz et al. (U.S. Patent No. 6,453,339). 

Group #/: Claim 37 

With respect to independent Claim 37, and particularly appellant's claimed "linking the toolbar 
to a portal of a user," the Examiner has admitted that "Ferguson fails to explicitly teach the 
linking of a portal of a user to a toolbar." 

The Examiner has argued, however, that "Sheldon teaches a system and method for use with web 
browser toolbars, similar to those of Ferguson," and that "Sheldon teaches the ability to 
customize the toolbar of a user interface by adding, deleting, or changing the function of an 
associated button (col. 1, lines 44-48), or further, dragging and dropping components into a 
toolbar or deskbar, as can be seen in col. 19, line 61 through col. 20, line 14, as the user can drag 
an address bar (similar to the bucket of Ferguson, as input is entered into the bar resulting in a 
desired output) into any deskbar." The Examiner has also argued that "Sheldon further states 
that the deskbar may be placed in an application window, such as a web browser, at col. 6, lines 
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62-65." The Examiner has thus concluded that "the incorporation of the GUI 246, and its link to 
the displayed portal in Ferguson, is made possible by the toolbar customization of Sheldon." 

Appellant respectfully disagrees and asserts that only generally teaching "toolbars [that] can be 
modified by adding or deleting buttons, or by changing the function associated with a button" 
(Col. 1, lines 44-46), as in Sheldon, fails to even suggest, let alone specifically meet appellant's 
claimed " linking the toolbar to a portal of a user " (emphasis added), as claimed. In addition, 
appellant respectfully points out that Sheldon does not teach that "the user can drag an address 
bar... into any deskbar," as noted by the Examiner. Instead, Sheldon simply discloses that a 
"user can drag and drop a toolbar associated with [an] application window on some other 
area... on the display screen 300," such that "a deskbar is automatically created containing the 
toolbar" (see Col. 20, lines 1-6), which clearly only relates to creating a deskbar that contains a 
selected toolbar. Appellant respectfully asserts that only generally disclosing a technique for 
creating a deskbar that contains a selected toolbar, as in Sheldon, fails to specifically teach 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "Sheldon explicidy 
outlines 'a method for customizing a deskbar', wherein 'if the user desires to customize the 
taskbar 310 by adding an address bar 600\ the use can drag the address toolbar 600 from the 
application window 800' and drop the address bar 600 on top of the taskbar 310.'" Further, the 
Examiner has argued that 'Sheldon does indeed teach that 'the user can drag and address 
bar... into any deskbar'." Additionally, the Examiner has stated that "the current citation of 
Sheldon has been expanded to cover col. 20, lines 15-41, where previously the examiner closed 
the citation at col. 20, line 14." 

Appellant respectfully disagrees and asserts that Sheldon merely teaches that "[i]n FIG. 20a, if 
the user desires to customize the taskbar 310 by adding an address toolbar 600 ! . the user can drag 
the address toolbar 600 from the application window 800* and drop the address toolbar 600 on 
to p of the taskbar 310 " such that c Tt1he address toolbar 600 is copied during the dragging 
process" (Col. 20, lines 25-3 1 - emphasis added). • 
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However, teaching that the user can drag the address toolbar from the application window and 
drop the address toolbar on top of the taskbar to customize the taskbar bv adding an address 
toolbar , where the address toolbar is copied during the dragging process , as in Sheldon, fails to 
suggest " linking the toolbar to a portal of a user" (emphasis added), as claimed. Clearly, 
copying the address toolbar during the dragging process and customizing the taskbar by adding 
an address toolbar, as in Sheldon, simply fails to even suggest "linking the toolbar to a portal of 
a user" (emphasis added), as claimed. 

Still yet, Sheldon's disclosure of a "deskbar [that] may simultaneously contain toolbars and 
toolbar components..., and [that] may exist in an application window" (Col. 6, lines 62-65), as. 
referenced by the Examiner, only suggests allowing a deskbar to exist in an application window, 
which does meet appellant's claimed " linking the toolbar to a portal of a user" (emphasis added), 
as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "as in previous 
Office actions,... incorporation of the 'bucket 5 of Ferguson into the customizable toolbar of 
Sheldon links the toolbar to the portal, as the bucket provides a direct link to the portal " 

First, appellant respectfully disagrees and again asserts that Sheldon's disclosure of a "deskbar 
[that] may simultaneously contain toolbars and toolbar components..., and [that] may exist in an 
application window" (Col. 6, lines 62-65), as referenced by the Examiner, only suggests 
allowing a deskbar to exist in an application window , which does not meet appellant's claimed 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Further, appellant respectfully asserts that Ferguson teaches that "[i]n the case of any secondary 
request being initiated by the user dragging-&-dropping a hyperlink from a Web page , the 
invention generates the appropriate HTTP request, fetches the data from the requested Web 
server 10, and archives the information in a cache on the user's hard drive 36" (Col. 7, lines 9-14 
- emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user desires to 
customize the taskbar 310 bv adding an address toolbar 600 ', the user can drag the address 
toolbar 600 from the application window 800 f and drop the address toolbar 600 on top of the 
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taskbar 310 " such that " [t]he address toolbar 600 is copied during the dragging process " (Col. 
20, lines 25-31 - emphasis added). 

However, dragging-&-dropping a hyperlink from a Web page, fetching the data from the 
requested Web server, and archiving the information in a cache on the user's hard drive, as in 
Ferguson, in addition to dragging the address toolbar from the application window and dro pping 
the address toolbar on top of the taskbar to customize the taskbar by adding an address toolbar. 
where the address toolbar is copied during the dragging process, as in Sheldon, fails to suggest 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. Clearly, fetching data 
and archiving the information, as in Ferguson, in addition to customizing the taskbar by adding 
an address toolbar and copying the address toolbar during the dragging process, as in Sheldon, 
simply fails to suggest any sort of "linking," much less " linking the toolbar to a portal of a user" 
(emphasis added), as claimed. 

Moreover, appellant respectfully disagrees with the Examiner's argument that "incorporation of 
the GUI 246, and its link to the displayed portal in Ferguson, is made possible by the toolbar 
customization of Sheldon." Appellant respectfully notes that the Examiner has expressly relied 
on the GUI 246 in Ferguson to meet appellant's claimed portal, as expressed by the Examiner's 
statement that "the open GUI [is] analogous to the claimed 'portal'" (see Page 2 of the Office 
Action). Since the Examiner has relied on the GUI 246 in Ferguson to meet appellant's claimed 
portal , such GUI clearly cannot have a " link to the displayed portal in Ferguson" (emphasis 
added), as noted by the Examiner. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "[a]ppellant... [has] 
misinterpreted the rejection of the claims with respect to the GUI 246 of Ferguson and the 
claimed portal" and that "GUI 246... teach[es] the claimed 'bucket', not the claimed 'portal', as 
argued by [ajppellant " Further, the Examiner has argued that "[t]his distinction is highlighted 
by Figs. 7 and 8 of Ferguson" where "Fig. 7 depicts the 'bucket' as referred to by the examiner." 
Additionally, the Examiner has argued that "the user drags links into the GUI 246, the links then 
being added to the 'portal', interpreted by the [E]xaminer as the list of links selected by the user 
in item 261 of Fig. 8." In addition, the Examiner has argued that "[t]he 'open GUI' referred to 
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by the [EJxaminer is not simply GUI 246, but instead the expanded GUI of Fig. 8, and more 
specifically, the list of links 261 " 

Appellant respectfully disagrees and asserts that Ferguson teaches that " ft1he O-Links list display 
261 is depicted in FIG. 8" such that "[w]hen the user opens the maximized graphical user 
interface (GUI) 251, this invokes the Q-Links Manager, as depicted in the flowchart FIG. 20 at 
164," and that "[i]n step 166, the invention obtains the O-Links list and displays it on the 
maximized GUI 251 in step 168" (Col. 30, line 66-Col 31, line 4 - emphasis added). Further, 
Ferguson teaches that "[i]f the user left clicks (or equivalent), on the link name or Web address 
of the O-Link which appears in the O-Links display list 261 that he/she wishes to view in the 
browser 62, the invention returns with that page from the invention's hard disk Cache 420" (Col. 
31, lines 39-45 - emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user 
desires to customize the taskbar 310 by adding an address toolbar 600 *. the user can drag the 
address toolbar 600 from the application window 800' and drop the address toolbar 600 on top of 
the taskbar 310 " such that u [t]he address toolbar 600 is copied during the dragging process" (Col. 
20, lines 25-31 - emphasis added). 

However, teaching a O-Link . which appears in the O-Links display list 261 . as in Ferguson, in 
addition to dragging the address toolbar from the application window and dro pping the address 
toolbar on top of the taskbar, where the address toolbar is copied during the dragging process, as 
in Sheldon, simply fails to suggest " linking the toolbar to a portal of a user" (emphasis added), 
as claimed. Clearly, a Q-Link appearing in the O-Links display list 261, as in Ferguson, in 
addition to dropping the address toolbar on too of the taskbar. as in Sheldon, simply fails to even 
suggest "linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Additionally, it appears that the Examiner has relied on an inherency argument regarding the 
above emphasized claim limitations. In view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific prior 
art showing of such claim features, in combination with the remaining claim elements is 
respectfully requested. (See MPEP 2112) 
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Further, in response, appellant asserts that the fact that a certain result or characteristic may 
occur or be present in the prior art is not sufficient to establish the inherency of that result or 
characteristic. In re Rijckaert, 9 F.3d 1531, 1534, 28 USPQ2d 1955, 1957 (Fed. Cir. 1993); In re 
Oelrich, 666 F.2d 578, 581-82, 212 USPQ 323, 326 (CCPA 1981). "To establish inherency, the 
extrinsic evidence 'must make clear that the missing descriptive matter is necessarily present in 
the thing described in the reference, and that it would be so recognized by persons of ordinary 
skill. Inherency, however, may not be established by probabilities or possibilities. The mere fact 
that a certain thing may result from a given set of circumstances is not sufficient.'" In re 
Robertson, 169 F.3d 743, 745, 49 USPQ2d 1949, 1950-51 (Fed. Cir. 1999). 

Still yet, the Examiner has argued that "[a]s the bucket of Ferguson is linked to the user portal, 
any incorporation of the bucket into a toolbar (as done by Sheldon) therefore links the toolbar to 
the user portal." 

Appellant respectfully disagrees and again points out that Sheldon merely discloses that a "user 
can drag and drop a toolbar associated with [an] application window on some other area. . .on the 
display screen 300," such that "a deskbar is automatically created containing the toolbar" (see 
Col. 20, lines 1-6), which clearly only relates to creating a deskbar that contains a selected 
toolbar. Appellant respectfully asserts that merely allowing a user to drag and drop a toolbar on 
some area of a display screen, where a deskbar containing the toolbar is created, as in Sheldon, 
fails to support the Examiner's allegation that Sheldon teaches "incorporation of the bucket into 
a toolbar " (emphasis added). To this end, the excerpts from Ferguson and Sheldon, as relied on 
by the Examiner, do not meet "linking the toolbar to a portal of a user," as claimed. 

In the Examiner's Answer mailed 05/28/2008, the Examiner has argued that "the combination of 
the bucket and portal of Ferguson into the customizable toolbars of Sheldon would indeed 
necessarily provide a link from the toolbar to the portal of a user." Further, the Examiner has 
argued that "Sheldon has been shown to teach a link between a bucket and a portal, as indicated 
by the ability of a user to drag and drop links into the bucket GUI 246, the links then being 
shown in the portal list 261." In addition, the Examiner has argued that "it [is believed] to be 
inherent that adding the bucket/portal functionality of Ferguson into the toolbar of Sheldon 
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would indeed provide a link from the toolbar to the portal, and is not 'established by probabilities 
or possibilities'." 

Appellant respectfully disagrees and asserts that Ferguson teaches that " HTTP requests [are! 
issued by dragging-&-dropping hyperlinks on the interface 246 of the invention" (Col. 6, lines 
63-65 r- emphasis added). Further, Ferguson teaches that "[i]n the case of any secondary request 
being initiated by the user dragging-&-dropping a hyperlink from a Web page , the invention 
generates the appropriate HTTP request, fetches the data from the requested Web server 10, and 
archives the information in a cache on the user's hard drive 36" such that "[u]pon receiving page 
requests from the list of links downloaded in the background (known as O-Links) . the files 
associated with the request are retrieved from the 'local hard drive cache" ' (Col. 7, lines 9-20 - 
emphasis added). Furthermore, Sheldon teaches that "[i]n FIG. 20a, if the user desires to 
customize the taskbar 310 bv adding an address toolbar 600 \ the user can drag the address 
toolbar 600 from the application window 800' and drop the address toolbar 600 on top of the 
taskbar 310 " such that " |Ylhe address toolbar 600 is copied during the dragging process " (Col. 
20, lines 25-31 - emphasis added). 

However, dragging-&-dropping hyperlinks on the interface 246, generating the appropriate 
HTTP request fetching the data from the requested Web server 10, and archiving the 
information in a cache on the user's hard drive 36, where the files associated with the request are 
retrieved from the 'local hard drive cache' upon receiving page requests from the list of links (Q- 
Links), as in Ferguson, in addition dragging and dropping the address toolbar 600 on top of the 
taskbar 310 in order to customize the taskbar by adding an address toolbar 600 . as in Sheldon, 
simply fails to suggest " linking the toolbar to a portal of a user" (emphasis added), as claimed. 
Clearly, adding the address toolbar to the taskbar by dragging and dropping , as in Sheldon, in 
addition to dragging and dropping hyperlinks on the interface 246 to generate a HTTP request, 
fetch the data, and archive the information in a cache, as Ferguson, simply fails to even suggest 
" linking the toolbar to a portal of a user" (emphasis added), as claimed. 

Furthermore, Sheldon teaches that "[t]he address toolbar allows the user to enter a Web address 
to open a Web page without having to open the web browser application program 37 (FIG. 1)" 
(Col. 14, lines 58-60 - emphasis added). However, adding the address toolbar to the taskbar, 
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which allows the user to enter a Web address to open a Web page without having to open the 
web browser, as in Sheldon, simply fails to even suggest " linking the toolbar to a portal of a 
user" (emphasis added), as claimed. Clearly, adding an address toolbar that allows the user to 
open a Web page, as in Sheldon, in addition to dragging and dropping hyperlinks on the interface 
246, generating the HTTP request, fetching the data, and archiving the information in a cache, as 
in Ferguson, simply fails to even suggest "linking the toolbar to a portal of a user" (emphasis 
added), as claimed. 

Appellant respectfully asserts that in view of the arguments made hereinabove, any such 
inherency argument has been adequately rebutted, and a notice of allowance or a specific prior 
art showing of such claim features, in combination with the remaining claim elements is 
respectfully requested. (See MPEP 2112) 

Again, appellant respectfully asserts that at least the third element of the prima facie case of 
obviousness has not been met, since the prior art excerpts, as relied upon by the Examiner, fail to 
teach or suggest aU of the claim limitations, as noted above. 

In view of the remarks set forth hereinabove, all of the independent claims are deemed 
allowable, along with any claims depending therefrom. 
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In the event a telephone conversation would expedite the prosecution of this application, the 
Examiner may reach the undersigned at (408) 971-2573. For payment of any additional fees due 
in connection with the filing of this paper, the Commissioner is authorized to charge such fees to 
Deposit Account No. 50-1351 (Order No. NVIDP380/P002194). 

Respectfully submitted, 

Bv: /KEVINZILKA/ Date: July 28. 2008 

Kevin J. Zilka 
Reg. No. 41,429 

Zilka-Kotab, P.C. 

P.O. Box 721120 

San Jose, California 95 172-1 120 

Telephone: (408)971-2573 

Facsimile: (408)971-4660 



